The present invention relates in general to the field of energy efficiency in information technology, notably to improving energy efficiency when processor performance management (PPM), or dynamic frequency and voltage scaling (DFVS) as it is also called, is employed. In particular, the invention relates to a power saving technique that works by reducing the effect on a power performance management algorithm or system of a computational load that is associated with a particular process (notably, a user application, system-level service or “daemon”).
Nowadays processor performance management is widely used in order to reduce the power consumption of computers and other devices/apparatus (especially portable devices—laptops, PDAs, mobile phones, etc.—which work using battery power for a large part of the time) containing a processor (notably a central processing unit, CPU). In this document the term “computing apparatus” shall be used as a general expression to designate devices/apparatus comprising a processor.
Modern processors are capable of functioning at a range of different clock frequencies and processor core voltages (Vcc). Each combination of an operating frequency and an operating voltage corresponds to a different standard of processor performance and is often referred to as a “performance state”, or an “operating point”, or a “P state” according to the Advanced Configuration and Power Interface standard (ACPI). Each performance state involves a different level of power consumption: the power consumption goes up in a linear fashion with CPU clock frequency and goes up with the square of the operating voltage. In other words, the following formula (1) is an approximation to how power consumption P varies with CPU clock frequency f and operating voltage V:P=CV2f  (1)where C is the processor capacitance.
As an example, Table 1 indicates the processor performance states that are supported by the 1.6 GHz Intel Pentium™ M processor.
TABLE 1FrequencyVoltage1.6GHz1.484 V←High Performance Mode1.4GHz1.420 V(highest power consumption)1.2GHz1.276 V1.0GHz1.164 V800MHz1.036 V600MHz0.956 V←Low Performance Mode(lowest power consumption)
Broadly speaking, processor performance management involves dynamically selecting a performance state for a processor based on the conditions applicable to the system at the time and/or based on a power management protocol which may have been specified by the user. Typically, a high performance state (highest possible operating frequency and voltage) will be selected when the percentage utilization of the processor is high and a power-saving low performance state (lowest possible operating frequency and voltage) will be selected when the percentage utilization of the processor is low, with intermediate states being selected in other circumstances.
The particular factors which influence the selection of processor performance state can be multiple, and vary from one system to another. Typical parameters which are taken into account include, but are not limited to: the processor utilization percentage (or processor “activity”), the user's power policy, the current battery level, and thermal conditions and events. Moreover, some PPM algorithms base their selection of processor performance state on predicted values of these parameters for an upcoming time period.
PPM can be implemented in a variety of ways, making use of features in the processor, BIOS and/or operating system. Examples of well-known PPM systems include AMD's powerNow!™, ARM's PowerWise Adaptive Voltage Scaling (AVS) and Intelligent Energy Manager (IEM), and Intel's Enhanced SpeedStep™ technologies.
One way of decomposing a PPM system is to consider that there is a control unit which decides on which processor performance state should be selected for a given time period, and a driver module which implements the desired setting of the processor performance state (for example, by writing a code into a register, internal to the processor, which identifies the next target processor performance state—as in the Intel SpeedStep™ system). In some cases the operating system may need to refer to the BIOS in order to determine the location of registers which hold the target processor performance state and/or the actual processor performance state. When the processor is instructed to change performance state, typically the processor will identify the desired operating voltage to an associated voltage regulator.
The present invention can be applied irrespective of the particular technique that is used to instruct a desired change in processor performance state and irrespective of the particular technique that is employed to implement an instructed change.
Often there will be a group of different power management policies and the user can select which policy he wishes the system to apply at a given time and/or can configure the policy. For example, the Microsoft Windows 7™ operating system specifies three power management policies (or “power plans”) called, respectively, “Performance”, “Balanced” and “Power Saver” and the user is allowed to customize these policies, for example, by specifying maximum and minimum limits on processor utilization in a given policy.
In many cases the system will operate in a PPM mode in which the load on the processor affects the performance state that is selected for the processor.
A computer (or other device having data processing capabilities) that is configured to implement a PPM policy which selects the processor performance state taking the processor activity into account will select a high performance processor state (i.e. high operating frequency and high operating voltage—with concomitantly high power consumption) whenever a computationally-intensive task is being processed. In general, the PPM module cannot distinguish between a high-priority task which should, indeed, be processed rapidly and a task which is non-urgent (i.e. where the user would tolerate slower completion of the task—i.e. a lower processor performance state—if this would lead to a reduction in power consumption).
In this regard, consider what happens when a computer user offers the resources of his system to a volunteer computing project, and his system is configured to implement a PPM policy which selects a processor performance state based, at least in part, on the computational load on the processor.
In volunteer computing, people contribute their computer resources to a large, and most often scientific, computing project. A well-known volunteer computing project is the climate modeling project run primarily by Oxford University via the climateprediction.net website.
In order to be able to participate in a volunteer computing project a user typically downloads a small application from a server associated with the volunteer computing project and installs this application on his computer. The application then downloads a block of data, performs a computation using the processor of the volunteered computer, uploads the result to the server, downloads the next block of data, and so on. Volunteer computing projects generally involve applications that are computationally-intensive, i.e. requiring the processor to perform mainly mathematical operations. Such applications are often referred to as “CPU-bound” applications.
In the most common case, volunteer computing applications are configured so that they execute only when the computer has been idle for a certain time, i.e. they run as a screen-saver. In order to evaluate the power consumption incurred in this kind of case (and others) a benchmark application was written, and this benchmark application was designed to perform a dummy computation so that it would mimic the behaviour of a CPU-bound user application. The benchmark application was run using the following apparatus: a Sony VAIO™ laptop (model PCG-Z1SP) using a 1500 MHz Intel Pentium™ M Banias processor featuring SpeedStep™ technology, using a GNU/Linux operating system with Linux kernel version 2.6.31 and configured so as to select the processor's performance state based on the percentage processor utilization.
When the benchmark application was run as a screen-saver on the above-described apparatus, the processor utilization (or processor load) was 100% during execution of the application (because it is a computationally-intensive application) and, accordingly, the PPM system selected the highest-performance processor state available. In these conditions about 57 seconds were required to complete the computation and roughly 1700 Joules of energy were used, making an average power consumption of 30 Watts. If the user is deliberately leaving his computer on purely so that a volunteer computing application can use his resources then all of this power is being consumed purely as a result of participation in the volunteer computing project.
By way of contrast, it is also possible to run a volunteer computing application (or other CPU-bound task) as a background task, for example while the user is using his computer for routine office work.
FIG. 1 illustrates the typical pattern of CPU activity when a user uses the above-mentioned laptop (configured as described) for routine office work. FIG. 1(a) illustrates an example of the typical pattern of variation in CPU load over time and FIG. 1(b) shows how the CPU clock frequency changes over the same time period under control of the PPM system (which is configured to select a high-performance processor mode when the CPU load is high but a low-performance processor mode when the CPU load is low).
It will be seen from FIG. 1(a) that average CPU load is low—generally below 20%—when the laptop is used for typical office work. FIG. 1(b) shows that the CPU's clock frequency also stays low, with occasional spikes to a higher frequency (for example, when the office application loads and decompresses an image). The power consumption when the laptop is used for routine office work is around 13 Watts which is practically the same as when the laptop is idle (i.e. CPU load close to zero).
When the benchmark application was run as a background task while the user was engaged in routine office work on the above-described test laptop configuration, the benchmark application made processor utilization jump to 100%, leading the PPM system to select a high-performance processor mode for the entire period when the benchmark application is being executed. The computation, once again, took about 57 seconds and over this time period the average power was 30 Watts. However, in this case it is fair to say that only 17 Watts “extra” power was being consumed over and above the power that the user would have required anyway in order to perform his routine office work (this represents a drop from 1700 Joules of energy used in the screen-saver case, to 969 Joules in the case of running in the background).
Thus, running a computationally-intensive application (or, more generally, a computationally-intensive task) as a background task while the user is engaged in using his computer is more energy-efficient than running the application as a screen-saver, but still involves expenditure of considerable additional energy.
Moreover, when the CPU-bound task was run in the background, raising the CPU load from a relatively low level to 100%, this soon placed a thermal stress on the CPU and the computer's fans started turning at full speed. The machine's noise soon became disturbing to the user and would be hard to tolerate for any extended period of time.
One approach that has been tried in the context of volunteer computing is to allow the user to restrict the fraction of time that his computer resources are available to the volunteer computing application. This functionality is provided by a software package called BOINC (Berkeley Open Infrastructure for Network Computing), which is often employed to deploy volunteer computing projects. If the user specifies that his computer resources are to be available to the volunteer computing project for less than 100% of the time then the BOINC manager will intermittently request the operating system to change the state of the application to “sleeping” so as to reduce the average CPU usage to the fraction specified by the user. For example, a user setting of 20% will lead the BOINC manager to run the application for 2 seconds and then “put the application to sleep” for 8 seconds on the assumption that, this being a computationally-intensive application, during the 2-second periods when the application runs the CPU load is 100%. When the application sleeps the CPU load will fall back to its idle level (or the level attributable to any other processes being executed by the CPU).
This facility that BOINC provides for a user to restrict the access that the volunteer computing application can have to the CPU does not lead to a reduction in the energy consumed by that application. This can be seen from the following:    let α be the user-setting of the allowed degree of CPU usage, where 0<α≦1;    P0 is the power consumption when CPU load is 0% (the CPU is idle);    P100 is the power consumption when CPU load is 100%;    T100 is the time that would be taken to perform the computation with CPU load at 100% and if the computation was uninterrupted; and    T is the actual time taken to complete the computation (including “sleep” periods).
The average power consumption should be P=αP100+(1−α)P0. However, the “extra” power consumption due to running the volunteer computing application (over and above the power used by the computer while idle) is only P=α(P100−P0).
Because of the sleeps introduced by BOINC the computation time grows from T100 to T=T100/α. Thus, the total “extra” energy consumed because of the running of the volunteer computing application E=P×T becomes (P100−P0)×T100, which is exactly the same as would have been the case without the “sleeps”.
In fact, it has been found in practice that when a computationally-intensive application's access to the CPU is restricted in this way the total energy consumed actually goes up. FIG. 2 shows how power consumption varied with the value of the parameter α (representing the proportion of the time the volunteer computing application has access to the CPU) in a case where a modified version of the benchmark application—adapted to reproduce the functionality provided by BOINC—was run on the test laptop configuration. FIG. 3 shows how computation time varied with the value of the parameter α in these experiments.
It can be seen from FIG. 2 that for almost all values of α the energy consumption is greater than for the case where there are no sleeps (i.e. the case where α=1). Moreover, FIG. 3 shows that for all values of α less than one the duration of the computation increases. In other words, using the facility provided by BOINC to restrict CPU usage appears to result primarily in increased energy consumption and lengthening of the time required to complete the computation.
Moreover, it has been found that when the parameter α is set to a value greater than 0.2 in the BOINC preferences then the thermal stress on the CPU brings the fans into operation and the machine quickly becomes unbearably noisy.
It will be seen from the above that whether a volunteer computing application (or other CPU-bound task, e.g. a user application, a system-level service, a daemon in a multi-tasking operating system environment, etc.) runs as a screen-saver or as a background task there is a considerable extra expenditure of energy involved in running this application. Part of the reason for this significant energy usage resides in the fact that execution of the volunteer computing application involves a high percentage CPU utilization rate (at or approaching 100%) and this leads the PPM system to select a high-performance processor mode even though this application does not truly require high performance from the processor (the user has no real need for the task to be run quickly—he could tolerate an extension of the time that is required for execution of this task to be completed).
Considered more generally, a PPM system which selects processor performance state based, at last in part, on processor utilization, can consume power at a considerable rate even in a case where some part of the processor load which prompts the selection of a high-performance state was not, in fact, urgent or high priority for the user.
Obviously, if the only tasks liable to be executed by a processor are non-urgent then the user could select a power management profile which sets the processor into a low-performance/low power-consumption state at all times. However, this is not appropriate if the processor is going to be faced with some tasks that are urgent and others which are not urgent. In such circumstances the user is probably better off leaving in place a PPM profile which takes the CPU load into account when setting the processor performance state.
US 2009/0199019 describes a technique whereby a computer system (notably its operating system) is configured so that there is an explicit assignment of priority levels to different workloads so that the PPM algorithm can base its selection of the processor performance state not just on the percentage processor utilization but also on the priority level of the workload in question. However, in order for existing computer systems (or other devices having data processing capabilities) to be able to make use of this technique it would be necessary to update the operating system on each system/device. This is an impractical task given that numerous different types of operating systems (and different operating system versions) are currently in use.